Notion 같은 호스팅 서비스는 가입하면 바로 쓸 수 있고, 서버와 백업과 보안 패치를 대신 맡아 줍니다. 대부분의 사람에게는 그것이 맞는 선택입니다. 이 글은 그래도 self-hosted wiki 를 고민할 만한 경우를 정리합니다.
1. 직접 운영이 맞는 경우
- 문서가 회사의 자산인데 데이터 위치를 직접 정해야 합니다. 데이터베이스가 내 서버에 있으면 백업 방식과 보관 기간을 내가 정합니다.
- 서비스의 요금이나 정책 변화에 묶이고 싶지 않습니다. 오픈소스 엔진은 소스가 남아 있으므로 계속 돌릴 수 있습니다.
- 자기 도메인으로 공개하고 싶습니다. 주소가 내 것이면 검색 유입도 내 것으로 쌓입니다.
- 스크립트로 문서를 다루고 싶습니다. 자기 서버라면 데이터와 API 를 마음대로 연결할 수 있습니다.
2. 직접 운영이 맞지 않는 경우
- 서버를 돌볼 사람이 없습니다. 백업과 업데이트를 안 하는 self-hosting 은 호스팅 서비스보다 위험합니다.
- 표와 데이터베이스 보기 중심으로 일합니다. 위키는 글과 링크가 중심입니다.
- 바로 오늘 시작해야 합니다.
3. 무엇을 기준으로 고를까
- 내보낼 수 있는가. 글이 평문으로 나와야 언제든 옮길 수 있습니다. AhaWiki 페이지는 텍스트이고
?action=raw로 원문을 볼 수 있으며, API 로 읽고 쓸 수 있습니다(Api). - 이력이 남는가. 누가 언제 무엇을 바꿨는지 볼 수 있어야 함께 쓸 수 있습니다. AhaWiki 는 리비전마다 히스토리, 비교, 줄별 작성자(blame)를 제공합니다.
- 권한이 어디까지 세밀한가. 공개 위키 안에 비공개 페이지가 필요하다면 페이지 단위 권한이 있어야 합니다(AccessControl).
- 누가 고칠 수 있는가. 소스가 공개되어 있어도 그 언어를 다룰 사람이 없으면 고치기 어렵습니다. AhaWiki 는 Scala 로 작성되어 있습니다(Scala Play Framework 위키 엔진).
4. 옮겨 올 때
한 번에 옮기지 않는 편이 좋습니다. 새 글부터 위키에 쓰고, 다시 볼 일이 생긴 옛 글만 그때 옮깁니다. 다시 안 보는 글을 옮기는 시간은 아낄 수 있습니다. Markdown 으로 내보낸 글은 InterpreterMarkdown 블록에 그대로 넣을 수 있습니다.
6. See Also
6.2. Similar Pages
Similar pages by cosine similarity. Words after page name are term frequency.